AllSaints is a 27-year-old global fashion retail business headquartered in the UK. We have brick and mortar locations all over the world and historically the business has depended massively on brick and mortar sales. And so it came as a surprise and relief to me that our customers were so willing to shift their behaviors during the pandemic and shop online, which helped us maintain healthy revenue numbers.
As AllSaints has grown and expanded across the globe we’ve seen that our legacy systems based on MySQL are not able to scale with the growing customer base. I joined AllSaints six years ago and began modernizing and simplifying our infrastructure to be better suited for success in the future. We’ve moved a lot of our services to GCP. And we’ve looked for opportunities to bring tools in house and reduce dependencies on third parties.
This post discusses our wholesale business which we built on CockroachDB. I’ll cover the pain points we wanted to address with the database, why we chose CockroachDB over Spanner, what our wholesale workload architecture looks like, and our plans for the future with CockroachDB.
Database Pain Points
A greenfield project like our wholesale platform is just such a delicious opportunity to use the new tools you’ve learned about and to right some of the wrongs of the past. The most pressing issue for us was to make sure we’re leveraging microservices to be more efficient. We never considered deploying MySQL next to Kubernetes. It isn’t a good fit.
We also wanted to avoid locking ourselves into one cloud provider. Getting locked in compromises the application architecture flexibility. Realistically, we don’t need that flexibility now, but we will in the future and that’s what we’re architecting for.
High availability cannot be a pain point for a retail business with high volume transactional workloads. Unfortunately, I’ve seen it in the past. It causes hairy problems like selling stock that doesn’t exist. This is not a pain that you ever want to feel.
Wholesale Business Database Requirements
Our architect, Ali Rankine, knew that we should use CockroachDB for this project. So I’ll have to afford all credit to him for that decision. He’s the type of innovative architect that reads all the latest research and he knew how comparable CockroachDB is to Spanner with the added value of maintaining our flexibility.
Our database requirements were roughly what you would expect for a use case that is essentially about product inventory and order management:
- A Managed Offering: We’re a small team. We want the database to look after itself.
- High Availability: For the reasons I stated above
- Kubernetes Compatibility: Using microservices helps us pivot/test quickly and makes us more resilient. Not all databases are a good fit with k8s. (CockroachDB is an excellent fit.)
- Good Performance: This is a tricky one. Performance in a distributed system is a different discipline. The CockroachDB sandbox environment will give you a good indication of what you can expect in production.
Why AllSaints Chose CockroachDB
CockroachDB checks each of the boxes above. And for those reasons it’s a good fit for this use case. But there are two other goals that we have as an organization, and CockroachDB fits with those too:
Future Proof Architecture
We want to future proof our infrastructure without adding a bunch of cost. We want to commit to tools that can grow with us. We rarely buy a tool off the shelf because we want to be in complete control of our applications so that we control the timeframe. CockroachDB is a worthwhile tool because it does not get in the way of our timeframes. And when you look at what CockroachDB is building it’s clear that they are focused on multi-region, multi-cloud deployments. Which is more horsepower than we need for this current workload. But it completely fits with where AllSaints is headed.
Simple, Efficient Architecture
We want our architecture to be more simple. I alluded to this a moment ago with the managed offering that we chose from CockroachDB. We are a small team with contractors doing a lot of the development work. We need the stack to be simple in order to maintain productivity. CockroachDB Dedicated is simple because it literally removes all the operational tasks. But it’s also just a simple database to work with. Spinning up your first node is so simple. Querying the data is simple. Adding users is simple. Scaling is simple. In this respect, CockroachDB fits with our ethos.
AllSaints Retail Wholesale Workload on CockroachDB
The wholesale application built on CockroachDB is an internal application used by the sales team to process orders with wholesale partners like Zappos, Bloomingdales, and Macy’s. Each season we load product data and order data into CockroachDB and the sales team uses that database to plan and execute their sales for that season. This is a new application and a relatively new line of business for AllSaints.
This application is built on 10+ microservices and that connect to a 9 node cluster deployed on CockroachDB Dedicated. This is phase one of the wholesale application. Right now everything runs behind CloudFlare Waf CDN. That’s how we’re currently locking down the application for internal use only. So we’re using Cloudflare DNS for the zone and Cloudflare zone lockdown rules that proxy back to the load balancer in GCP that forward traffic to the Kubernetes cluster.
Take a look at the architecture:
The Ease of Using CockroachDB
The fundamental promises of CockroachDB like HA and Kubernetes compatibility have all been true. Which is as expected.
I’ve been pleasantly surprised by the ease of use. Our clusters were spun up for us because we chose the managed solution but it’s nice that we’ve never had to ask for assistance since they were spun up. And our developers have had an easy time adapting to a new database. There was a situation where they needed to make a tweak to performance on a high insert workload and it was all very straightforward because the documentation is so strong.
As someone who is an administrator for most things in the company it’s really nice for me that it’s so easy to add new users and new application users.
And the DB Console has become one of two tabs that I have open at all times (the other being the Google Cloud Console). I’m not a developer, but I like to be hands-on. I like the web based monitoring so I can see what’s happening in real time. The internode latency is not super important at the moment. But when we’re geo-partitioning data in different regions that latency will be fun to watch.
Adding All Product Data to CockroachDB
AllSaints is growing and the wholesale side of the business is growing particularly fast. We’re basically limited, to this point, by the quantity of product that we have to sell. So, now we know that we can plan for more production and use the wholesale business to sell that product.
All of which is to say that this workload will expand into multiple regions. We’ll have a reason at that point to start using CockroachDB’s geo-partitioning feature for performance and data storage regulation reasons. And we’ll integrate with EDI’s. We currently use RabbitMQ on our side to integrate with the database, but we’ll add the EDI’s to be able to communicate with wholesalers.
Most importantly, we plan to increase the product data being stored on CockroachDB. Right now CockroachDB is storing all the relevant wholesale product data. But we’re planning to move all the product data onto CockroachDB so that we can have all the inventory in one place which creates a single, holistic view of all the data.
Generally speaking, CockroachDB has been exactly what we thought it would be and a little more. But this is just the beginning. We’re looking forward to growing the business and growing our use of CockroachDB alongside it.
